cgmes: fix voltage regulating control defined at busbar section #3666
Conversation
Signed-off-by: marquesja1 <[email protected]>
Signed-off-by: marquesja1 <[email protected]>
marqueslanauja
requested review from
jeandemanged,
rcourtier and
zamarrenolm
|
Hi @marqueslanauja ,
|
Signed-off-by: marquesja1 <[email protected]>
I've implemented a new approach. It has no impact on CPU usage. Using your Python code, I created a more complex case that I used as a unit test. Here is the diagram for the new case: 
|
Hi @marqueslanauja , |
cgmes/cgmes-conversion/src/main/java/com/powsybl/cgmes/conversion/RegulatingTerminalMapper.java
Outdated
Show resolved
Hide resolved
| } | ||
| Bus busBreakerView = context.network().getBusBreakerView().getBus(busbarSectionCgmesTerminal.topologicalNode()); | ||
| return busBreakerView != null | ||
| ? EquivalentTerminalFinderVoltageControl.best(EquivalentTerminalFinderVoltageControl.findTerminalsBusBranch(busBreakerView.getVoltageLevel(), busBreakerView)) |
There was a problem hiding this comment.
not sure here, my understanding is that findTerminalsBusBranch does not consider opened switches ?
There was a problem hiding this comment.
Both open and closed switches are considered. The regulating terminal is defined during the convert process, and at that point only the EQ file is considered. Switches are created as open or closed based on their normal state. Later, during the update phase, the switch statuses are updated using the SSH file
Signed-off-by: marquesja1 <[email protected]>
jeandemanged
left a comment
jeandemanged
left a comment
There was a problem hiding this comment.
As I mentioned in the issue #3560:
- current practice in CGMES importer is to avoid defining fictitious equipment and instead try to find an equivalent terminal, however only one TopologicalNode is examined, other topological nodes connected via closed retained switches are ignored, but could be considered.
- the current practice may be considered flawed: in case topology is changed (switches opened or closed) the chosen terminal may not be the relevant one anymore. To solve this we could instead define a fictitious zero loads to represent busbar sections and use this fictitious load terminal to be the regulating terminal.
bullet 1 is implemented, but not considering switches open/closed status. The fix works perhaps 90 % of the cases, but still is better than current situation...
Bullet 2 left for potential future work.
OK for me to merge as long as @rcourtier and @zamarrenolm also agree to merge.
…d_at_busbar_section
…d_at_busbar_section
|
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
fixes #3560
What kind of change does this PR introduce?
Bug fix
What is the current behavior?
When a model is imported in busBreaker level, busbar sections are not imported. As a result, voltage regulating terminals defined on busbar sections are ignored, and the voltage regulating control is localized by setting the generator terminal as the regulating terminal.
What is the new behavior (if this is a feature change)?
When a nodeBreaker model is imported as busBreaker and voltage regulating controls are defined on busbar sections, we attempt to identify an equivalent IIDM terminal that is connected to the busbar section through switches.
The method
RegulatingTerminalMapper.findSwitchCgmesTerminalIdForConnectivityNodeis a bit cpu intensive but it will only be used when a nodeBreaker model is imported as busBreaker and voltage regulating terminals are defined on busbar sectionsA new approach has been implemented without using the previous method (
RegulatingTerminalMapper.findSwitchCgmesTerminalIdForConnectivityNode). This new approach has no impact on CPU usage. The previous method has been removed.Does this PR introduce a breaking change or deprecate an API?
If yes, please check if the following requirements are fulfilled
What changes might users need to make in their application due to this PR? (migration steps)
Other information: